Amazon RDSの新しいDBエンジン「Aurora」について気になるトコロ #reinvent
よく訓練されたアップル信者、都元です。RDS for Aurora、気になりますね！ MySQL 5.6との高互換性を謳っている製品なので、RDS for MySQLとの比較という視点で、色々見て行きましょう。
まず、Auroraは「RDBをAWSが作りなおしたら？」というテーマで新しく作られた製品であるため、インターフェイスをMySQL 5.6互換としているだけで、中身は全く別物であろうと推測されます。これにより、MySQLの5倍のパフォーマンスを実現しています。
お値段
まずは気になるお値段。発表時にはオープンソースDBの価格で、と謳っていますが、具体的にはこんな感じでした。（現在はus-east-1でのpreview公開のみなので、このリージョンで比較）
| class | MySQL | Aurora |
|---|---|---|
| db.r3.large | $0.240 | $0.29 |
| db.r3.xlarge | $0.475 | $0.58 |
| db.r3.2xlarge | $0.945 | $1.16 |
| db.r3.4xlarge | $1.890 | $2.32 |
| db.r3.8xlarge | $3.780 | $4.64 |
開発コストは掛かったでしょうから、さすがにMySQLと同価格、とは行かなかったようですが、概ね1.2倍強の価格で提供されています。詳しくは料金表を御覧ください。
ちなみに、インスタンスクラスの選択肢は、現状上記5種類のようです。開発環境用にt2シリーズも欲しいですねぇ…。
MySQL 5.6からのマイグレーション
マイグレーションには2つの選択肢があります。1つ目は「mysqldump & mysqlimport」、単純にダンプして、それをAuroraに食わせればいいんですね。見た目にも分かりやすいです。
もう一つはMySQLのDBスナップショットからAuroraのインスタンスを立てることもできるようです。これは簡単。
制限事項としては2つ。MyISAMエンジンを使っている場合は、予めInnoDBに変換しておく必要があります。そもそもRDS for MySQLでは推奨されていなかったエンジンではありますが。
もう一つの制限事項はinnodb_file_per_tableオプションが有効な状態で作られたテーブルもサポートしないようです。従って、このオプションは無効にし、対象テーブルも元に戻しておく必要があります。
ストレージの拡張
従来のRDSでは、ストレージ容量が不足した場合、手動で領域拡張の操作をする *1必要がありました。
これは「あらゆるシステムは、正常なライフサイクルをひた走っていたとしても、管理をしなければ、ディスク容量不足による障害を避ける事ができない」という悲しい現実を表しています。RDS for MySQLを立てた場合は、CloudWatchによる空き容量アラームは必須です。アプリケーションがバグってなくても、いつか容量は底をつくのですから…。
一方Auroraでは。Auroraのストレージは、10GB単位で勝手に増えます！ SUGEEE！ 地味かもしれませんが、これは嬉しい特徴です。正にAdministration Free *2！
ちなみに、最低ストレージ容量は10GBとのことです。
インスタンスクラスのスケールアップ
これは、正直RDS for MySQLとあまり変わらないようです。ダウンタイムも存在します。
バックアップとリストア
ドキュメントに「Automated backups are always enabled」とありました。つまり、逆に、自動バックアップを止めることは出来ないのかもしれません。まぁ、普通バックアップしますよね。
その他、マニュアルバックアップや、リストアの方法、Point-in-timeリカバリ等は、MySQLと同等のようです。
多重化（耐障害性と読み込み性能拡張性）
RDS for MySQLでは、Multi-AZとRead-Replicaという2通りの多重化方式がありました。前者が障害耐性を担い、後者が読み込み性能拡張性を担っています。
しかし、逆に言えば。Multi-AZとして、プライマリの他にセカンダリとして、もう一台分のリソースを消費しつつも、障害が無い限り、セカンダリが利用されることは無く、読み込み性能拡張性に寄与することはできませんでした。
そして、Read-Replicaは、読み込み性能拡張性に寄与するものの、障害耐性への寄与は薄い（Multi-AZほどではない）のが現実でした。Multi-AZは障害検知し次第、自動的にフェイルオーバーが起こり、自己修復を行いますが、Read-Replicaは自動的な復旧は行いません。手動で（旧）マスタを切り離し、マスタ昇格することはできるので、障害耐性への寄与が無いわけではないとは思います。
そんな中、Auroraでは「Aurora Replica」と呼ばれる多重化方式のみが提供され、障害耐性と読み込み性能拡張性の両方をカバーするようになっています。つまり、通常はリードレプリカとして機能しつつ、障害時のフェイルオーバー先としても機能します。AWS上で本番用RDSを運用する場合は、通常Multi-AZとするはずです。その隠れた1台が、リードレプリカとしても利用できると考えると、嬉しいですね。
ところで、Aurora Replicaは、書き込まれたデータを3つのAZに2つずつ、計6箇所に多重化します。6つのストレージのうち、同時に2つに障害が発生しても書き込み可用性を損ないません *3！ そして、同時に3つに障害が発生しても読み込み可用性を損ないません *4！ 凄いですね。
さて、実際にフェイルオーバーが起こる時。Aurora Replicaがある場合はレプリカのマスタ昇格及びエンドポイントのCNAMEフリップが発生します。これはRDS for MySQLと同じですね。ただ、所要時間は短縮され、平均的には2分とのことです。そしてレプリカが無い場合は、新しいインスタンスを作ることになるため、15分程度掛かるとのこと。ちなみに、Aurora Replicaに対して読み込みトラフィックがある中で、フェイルオーバーによるマスタ昇格が発生すると、一時的にインタラプトが発生するようです。
次にレプリカの方式です。MySQLのレプリカでは、Multi-AZでは各インスタンスに属するストレージに対する同期書き込み、Read-Replicaでは非同期書き込みを行っていました。つまり、後者にはレプリカ・ラグがあると言えます。実際、MySQLレプリカには秒オーダーのラグが発生することがあります。
Auroraレプリカは、どうやら複数のノードで同じストレージを共有 *5しているようです。そのため、論理的にはレプリカ・ラグは無いことになります。まぁ、実際には10ms程度のラグがあるようですが、ほぼ問題にならないかと。
ということで、クラッシュリカバリ時の挙動にも差が出てきます。MySQLのクラッシュリカバリでは、5分毎のチェックポイントからredoログを適用（その後に整合性チェック）するというリカバリ方式をとっていました。Auroraではそもそも共有ストレージなので、この時間消費がありません。
まとめ
個人的には、Multi-AZとRead-Replicaの統合が嬉しかったです。早く使ってみたいですね！
